Methods for providing long term storage and retrieval of customized transaction card images

ABSTRACT

The present invention provides a method for providing long term storage of customized transaction card images, comprising the steps of approving or rejecting a selected customized image, marking the customized image as approved or rejected, packaging the customized image into an image file for a transaction card issuer, sending the image file to the transaction card issuer via a secure transfer process, and sending the image file to long term storage.

REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 60/800,964, filed May 17, 2006, the content of which isincorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The invention broadly relates to transaction card customization and moreparticularly to methods for providing long term storage and retrieval ofcustomized transaction card images.

BACKGROUND OF THE INVENTION

Transaction cards, such as credit cards, debit cards, membership cards,promotional cards, frequent flyer cards, and identification cards, arewidely used throughout the world. Such transaction cards may include avariety of different indicia to identify the card, the individual usingthe card, a transaction account (e.g., a transaction card account), andother features. The indicia may include a string of alphanumericcharacters, a bar code or an encoded magnetic strip attached to thecard. Transaction cards related to financial transactions have amagnetic stripe which runs longitudinally across the face of one side ofthe card and have a plurality of numbers, expiration date and a nameembossed thereon.

It is known to apply a customized image to a membership card, debitcard, or other transaction card. Specifically, the customized image maybe created and applied to the card from a remote location such as at theapplicant's computer, wherein the applicant may edit the customizedimage using software operated by a website server. However, such methodssuffer from a number of known drawbacks, including a failure to providelong term storage and retrieval of customized transaction card images.

SUMMARY OF THE INVENTION

The present invention is directed to methods for providing long termstorage and retrieval of customized transaction card images.

According to the invention, a preferred method for providing long termstorage of customized transaction card images comprises (i) approving orrejecting a selected customized image, (ii) marking the customized imageas approved or rejected, (iii) packaging the customized image into animage file for the card issuer, (iv) sending the image file to thetransaction card issuer via a secure transfer process, and (v) sendingthe image file to long term storage. The step of approving or rejectingthe selected customized image is performed by an image reviewer of atransaction card issuer, whereas the steps of marking the customizedimage as approved or rejected, packaging the customized image into animage file for the transaction card issuer, sending the image file tothe transaction card issuer via a secure transfer process, and sendingthe image file to long term storage are performed by an image reviewapplication. The step of sending the image file to long term storage isperformed after 30 days has elapsed since sending the image file to thetransaction card issuer.

According to the method, the step of sending the image file to long termstorage comprises sending the image file to an image archive database ofa transaction card franchiser, which is performed to supplement a cardreplacement program of the transaction card issuer. In addition, thestep of sending the image file to long term storage may be performedafter a predetermined amount of time (e.g., 30 days) has elapsed sincesending the image file to the transaction card issuer. A transactioncard applicant may request a customized image for lost, stolen, orexpired cards through an image administrator. This may entail logging onto the image administrator, requesting the customized image through acard replacement section of the image administrator, navigating the cardreplacement section, entering a unique image identifier, and receivingconfirmation that the request is in process. Upon receiving the request,the image administrator locates the customized card image via the uniqueimage identifier, automatically approves the request, retrieves thecustomized image from an image archive, and places the customized imagein an image queue. The customized image may then be sent to a cardprocessor for transaction card replacement.

In accordance with the principles of the invention, a preferred methodfor providing retrieval of customized transaction card images from longterm storage involves the steps of (i) providing retrieval of customizedtransaction card images from long term storage, including requestingretrieval of a customized image through an image review application,(ii) retrieving the customized image from long term storage using theimage review application, (iii) setting image status to re-send, (iv)packaging the customized image into a customized image file, and (v)sending the customized image file to the transaction card issuer via thesecure transfer process. The steps of requesting retrieval of thecustomized image and retrieving the customized image from long termstorage are performed by a transaction card issuer, while the steps ofsetting customized image status to re-send, packaging the customizedimage into a customized image file, and sending the customized imagefile to the transaction card issuer are performed by the image reviewapplication.

The method for providing retrieval of customized transaction card imagesfrom long term storage may further comprise the step of sending thecustomized image to a card processor for transaction card replacement.The customized transaction card images are stored in an image archivedatabase of a transaction card franchiser, wherein storing thecustomized transaction card images on the franchiser database isperformed to supplement a card replacement program of the transactioncard issuer. A transaction card applicant may request a customized imagefor lost, stolen, or expired cards through an image administrator. Therequest may involve logging on to the image administrator, requestingthe customized image through a card replacement section of the imageadministrator, and entering a unique image identifier. Upon receivingthe request, the image administrator locates the customized card imagevia the unique image identifier, and automatically approves the request.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating card customization processflow, in accordance with the principles of the present invention;

FIG. 2 is a schematic diagram illustrating a system for transaction cardcustomization, in accordance with the principles of the presentinvention;

FIG. 3 a is a schematic diagram illustrating a preferred method forproviding long term storage of customized transaction card images, inaccordance with the principles of the present invention; and

FIG. 3 b is a schematic diagram illustrating a preferred method forproviding retrieval of customized transaction card images from long termstorage, in accordance with the principles of the present invention.

DETAILED DESCRIPTION

In the following paragraphs, the present invention will be described indetail by way of example with reference to the attached drawings.Throughout this description, the preferred embodiment and examples shownshould be considered as exemplars, rather than as limitations on thepresent invention. As used herein, the “present invention” refers to anyone of the embodiments of the invention described herein, and anyequivalents. Furthermore, reference to various feature(s) of the“present invention” throughout this document does not mean that allclaimed embodiments or methods must include the referenced feature(s).

The present invention is directed to methods for providing long termstorage and retrieval of customized transaction card images. In apreferred method for providing long term storage of customizedtransaction card images, an image reviewer of a transaction card issuerapproves or rejects a selected customized image submitted by atransaction card applicant, and then marks the customized image asapproved or rejected. In response, an image review application packagesthe applicant submitted customized image into an image file for the cardissuer, and sends the image file to the transaction card issuer via asecure transfer process. After a predetermined amount of time, the imagereview application sends the image file to long term storage.

The present invention is also directed to a preferred method forretrieving customized transaction card images from long term storage.According to the method, the transaction card issuer requests retrievalof a customized image through an image review application, and thenretrieves the customized image from long term storage using the imagereview application. The image review application then sets the imagestatus to re-send, packages the customized image into a customized imagefile, and sends the customized image file to the transaction card issuervia a secure transfer process. It should be appreciated by those ofordinary skill in the art that the principles described herein may beapplied to many types of transaction cards such as debit cards, creditcards, ATM cards, membership cards, identification cards and frequentflyer cards, without departing from the scope of the invention.

According to the principles of the invention, custom-designedtransaction cards may be provided for both existing and new applicants.Customization may be offered through a country-specific website for newaccounts during the application process or for existing accounts afterlog-on has occurred. The card customization process enables applicantsto customize the front of the card using a dedicated website that isaccessed through the issuer's website. Applicants may select personalphotos, artwork or any image (subject to image-review standards) forplacement on the card. The customization process allows applicants toupload a personal image, refine and design the final look of the card,and submit the final image for image review. The invention is designedto facilitate complete issuer control with minimal impact to theinternal acquisition and account maintenance infrastructure. Issuersmanage digital images stored on a card customization system, whilefunctional tools available to issuers accommodate image acceptance orrejection for printing subject to predetermined minimum designstandards. Upon approval, an image file is created and sent to theissuer. The issuer then formats the print image and applicant accountinformation (e.g., applicant name, account number, and expiration date)into a merged record. A file is created and sent to the issuer'sselected card production service provider for printing, personalizationand distribution.

Referring to FIG. 1, a flowchart 10 is provided illustrating the cardcustomization process flow including custom card image creation, issuerimage review, and card production. Initially, an applicant 14 accessesan issuer website 16. Upon entering the appropriate information such asan applicant name and password, the applicant 14 is passed through anaccess portal 20 to a card customization services website 24 (providedby a transaction card franchiser) for adding a customized image on afront surface of their transaction card. In accordance with theprinciples of the invention, the customized image is subject to reviewby the issuer and/or an image administrator of the franchiser.

With further reference to FIG. 1, custom card image creation isperformed on the card customization services website 24, whereby theapplicant 14 uploads a personal image, creates a custom image andsubmits the image to the issuer for approval. This information may bestored in a franchiser image database 28 as well as in an issuerdatabase 44. With respect to issuer image review, an issuer 32 mayaccess an online image administrator website 40 via an issuer accessportal 36. On the image administrator website 40, the issuer 32 conductsan image review and submits the results including an acceptance orrejection of the image to the issuer database 44. For each applicant 14,an account data file 50 from the issuer database 44 is combined with acorresponding image data file 54 from the issuer database 44 to form acomposite merged file 58. With regard to card production, the mergedfile 58 is sent to a card producer 62 for production and distribution ofthe customized card 66 to the appropriate applicant 14. The process mayoptionally involve a card distributor 70, such as a bank or otherdistributor, for delivering the customized card 66 to the appropriateapplicant 14.

Referring to FIG. 2, a system 100 for transaction card customization inaccordance with the principles of the present invention comprises aplurality of issuer country websites 112, 114, 116, a centralized issuerhub 120, card customization services 124, an image administrator 126, asyndication layer 130, and a plurality of dedicated country-specificwebsites 132, 134, 136. The system 100 of the invention provides acentralized solution offering a single point of website integration.Applicants may enter the system 100 at a browser-based user interfacethrough their local issuer country website 112, 114, 116. Each localissuer country website 112, 114, 116 may be implemented using its ownproprietary computer software application. The image administrator 126may be implemented using a computer software application comprisingmachine readable or interpretable instructions for controlling a remoteimage processor for approving or rejecting various applicant images.After card customization, the system 100 may be employed to route cardcustomization files to one or more card finishers for production.

According to the invention, the centralized issuer hub 120 may comprisea server that coordinates all traffic among the issuer country websites112, 114, 116, the card customization services 124, and the imageadministrator 126. Card customization services may comprise a website124 that recognizes the issuer country and processes applicant requests.In this manner, information provided by the applicant is used to launcha dedicated country-specific website 132, 134, 136, whereby thesyndication layer 130 “wraps” the correct country-specific contentaround a base website and serves up a country-specific version of thebase website to the applicant's browser. The base website includes thecore components that make up the consumer-facing card customizationsoftware application, wherein the same base code may be reused for allcustomers. The base website includes basic features and functionalitywithout any issuer-specific enhancements or issuer-specific brandingsuch as foreign language, colors, artwork and website links.

With further reference to FIG. 2, the card customization serviceswebsite 124 may be implemented using a computer software applicationcomprising machine readable or interpretable instructions formanipulation of remote images. In particular, the software applicationmay comprise a browser-based user interface displaying a graphicalrepresentation of an image that is uploaded by an applicant from aremote location, wherein the image may be manipulated by the applicantfrom the remote location. By way of example, the original applicantimage may be uploaded from the customer's own computer. Regarding imagemanipulation, the applicant may perform operations such as imagerotating, image re-sizing, image flipping, image mirroring, and imagepositioning including placing the original image within a window regionof the card. According to the invention, the final image displayed onthe transaction card may be restricted to a predetermined area on thetransaction card, such that the rest of the card may contain featuressuch as logos, holograms and card type indicators.

In operation, the card customization services website 124 preferablymirrors the issuer country website 112, 114, 116. Accordingly, issuersparticipating in the program coordinate with card customization servicesto prepare system interface branding elements and artwork that appear onboth websites. Elements for such system interface branding may includewithout limitation: (1) an issuer logo; (2) a link for issuer home inthe footer; (3) a link for privacy policy in the footer; (4) a link for“Contact Us” in the footer; (5) terms and conditions; (6) a cardcustomization and tag line; (7) all images on the site; (8) a sitelanguage translation (if not English); (9) a color scheme for header,text and buttons; (10) font; (11) frequently asked questions; (12) anapproved electronic card form in vector format. In addition, a vectorcard format file may appear as an “overlay” to provide applicants with asubstantially exact replica of the card as it will be received.Accordingly, the overlay preferably shows all account informationplacement (i.e., “valid thru” date, embossing, issuer logo, etc.) andcard attributes (i.e., MIA, engraved areas, etc).

Upon completion of the applicant image submission and return to theappropriate issuer country website 112, 114, 116, card customizationinformation is stored on the issuer country website 112, 114, 116 usinga token unique-ID and the image file name. Issuers receive the imagesand image information from card customization services 124 for storageafter receiving custom card image approval or rejection. For example,card customization services 124 may create a zip file of card images fortransmission to the issuer. The zip file may contain one or more imagefiles created using an image ID as the filename and a comma separatedvalue (CSV) file having fields including, but not limited to (i) imageID, (ii) date created, (iii) status date (last action date), (iv) status(approved or rejected), (v) reject reason ID (if applicable), and (vi)reject reasons (if applicable).

With further reference to FIG. 2, the system 100 includes one or moreintegration points 140, 142 wherein the card customization softwareapplication interacts with the issuer's software application. Morespecifically, integration point 140 is disposed between the centralissuer hub 120 and card customization services 124. At integration point140, the issuer's software application is integrated with the cardcustomization software application, such that the applications functionsubstantially seamlessly as one consistent application. Another point ofintegration (integration point 142) is disposed between the centralissuer hub 120 and the image administrator 126. At integration point142, the issuer's application software is integrated with the imageadministrator software application, so that the applications functionsubstantially seamlessly as one consistent application. Particularly,integration point 142 refers to the transfer of approved or rejectedimage information to the issuer country website 112, 114, 116, so thatthe appropriate issuer knows which cards to produce, and which cards topass to their customer service department (e.g., for cards containingrejected images).

In accordance with the principles of the invention, the issuer countrywebsites 112, 114, 116 are the entry point for an applicant to locatetheir issuer (e.g., the applicant's on-line banking provider). When theapplicant is passed to card customization services 124 to complete thecustomization function, the applicant is served up a dedicatedcountry-specific website 132, 134, 136 for card customization. Accordingto the invention, each dedicated country-specific website 132, 134, 136may contain its own language, branding, advertising and other qualities,depending on the country of origin of the selected issuer countrywebsite 112, 114, 116. Additionally, the preferred system 100 of theinvention provides an automatic upgrading of all dedicated websites 132,134, 136 simultaneously. More particularly, any changes applied to basewebsite functionality may be automatically enabled on each issuercountry website 132, 134, 136. Otherwise, the appropriate changes wouldhave to be entered manually with respect to each individual dedicatedwebsite 132, 134, 136.

Referring to FIG. 3 a, a preferred method 300 for providing long termstorage of customized transaction card images will now be described. Forexample, the method 300 may be employed by a transaction card franchiserto supplement the card replacement program of a transaction card issuer.Specifically, the transaction card franchiser provides long term imagestorage (e.g., beyond the standard 30 days) and image access foremergency card replacement by way of an image archive system.Accordingly, an applicant that loses a transaction card having acustomized image may receive a replacement card with the same customizedimage. The method begins with step 310, in which an image reviewer 315approves or rejects a selected customized image. In step 320, an imagereview application 325 marks the customized image as approved orrejected according to the image reviewer's decision, and packages thecustomized image into an image file 327 for the transaction card issuer335. Step 330 involves the image review application 325 sending theimage file 327 to the transaction card issuer 335 via a secure transferprocess. In step 340, the image file is sent to long term storage 345(e.g., in a franchiser database) after a predetermined amount of time.By way of example, the predetermined amount of time may comprise 30days.

Referring to FIG. 3 b, a preferred method 350 for providing retrieval ofcustomized transaction card images from long term storage for thepurpose of card replacement will now be described. In step 355, thetransaction card issuer 335 requests the retrieval of a customized imagethrough the image review application 325. Reasons for the transactioncard retrieval request may include the replacement of lost cards, stolencards, and expired cards. Step 360 involves retrieving the appropriatecustomized image from long term storage 345 using the image reviewapplication 325. In step 370, the image review application 325 sets theimage status to re-send and packages the customized image into acustomized image file 377. Step 380 involves sending the customizedimage file 377 to the transaction card issuer 335 using the image reviewapplication 325 via the secure transfer process.

In accordance with the principles of the present invention, the methodsof FIGS. 3 a and 3 b may be utilized to automate various functions,including: (1) requesting customized card images for lost, stolen, orexpired cards through the image administrator 126; (2) retrievingcustomized card images from the franchiser archives (i.e., long termstorage); and (3) sending customized card images to card producers forreplacement. To request a customized card image for lost, stolen, orexpired cards through the image administrator 126, an applicant (i) logson to the image administrator 126, (ii) requests the appropriatecustomized image through a card replacement section of the imageadministrator application, (iii) navigates the card replacement section,(iv) enters a unique image identifier, and (v) receives confirmationthat the request is in process. In response, the image administrator 126locates the customized card image via the unique image identifier,automatically approves the request, retrieves the customized image fromthe franchiser archives and places in the re-send status, and places thecustomized image in an image queue. Sending of the image to a cardprocessor for replacement merely involves sending the image (e.g., aspart of a subsequent batch of image files) to the card producer.

The image administrator 126 disclosed herein is used in the process ofimage acceptance, rejection and review. Using a predetermined set ofimage guidelines (such as including a list of prohibited subjectmatter), an issuer reviewer 315 decides whether to approve or reject theimage. To approve an image, an “Approve” button is clicked followed by a“Submit” button, which completes the review/approval process. Rejectedimages follow the same process except that a “Reject” button is clickedand a series of reject reason descriptors are displayed, wherein allreject reasons that apply are checked. Additionally, the imageadministrator 126 may include an image archive that stores previouslyreviewed images. This information is used to provide an historicalreference to provide precedence with respect to the types of images thathave been approved or rejected. Each stored image may be referenced bythe date of approval or rejection, the original date of receipt, thedate of initial review and the reasons for rejection. The imageadministrator 126 preferably provides issuer reviewers 315 with varioustools for image review. These image administrator tools may be accessedthrough the centralized issuer hub 120.

According to the invention, card issuers are responsible for providinginitial image review including the rejection of inappropriate images.Prohibited subject matter for a customized images on any transactioncard may include without limitation: (1) sexual subject matter of anynature; (2) political subject matter of any nature (except if theaffinity or co-branded partner is a political organization); (3)offensive racial/prejudicial subject matter of any nature; (4) offensivereligious subject matter of any nature; (5) advertising of any nature;(6) a portrait of an adult (including the applicant) intended foridentification purposes; (7) self-promotion of any nature (e.g.,personal business card); (8) copyrighted material of any nature; (9)branded products/services, including abbreviations, acronyms and/orsymbols of any nature (except those identities approved for co-brandedcard programs); (10) solicitations, including telephone numbers orservices of any nature (e.g., 900 or 800 numbers); (11) celebrities,musicians, athletes, entertainers, public figures, etc., of any nature;(12) affiliation with groups that are determined to be of a “sociallyunacceptable” nature; (13) subject matter of any nature that mightresult in card acceptance confusion by merchants; and (14) subjectmatter of any nature that might result in card fraud.

According to the invention, applicant access to the card customizationservices website is initiated through a selected issuer country websiteby creating a message requesting access to the card customizationwebsite. An issuer created token may required in the header area of themessage to identify the issuer as a participant in the program prior towebsite connection. By way of example, tokens may be created usingvarious data elements including bank name, ICA, returning URL, portfolioand a unique ID. The returning URL data element contains the cardcustomization services web address. The unique ID data element uniquelyidentifies an applicant and facilitates mapping of the custom card imageto the transaction card. Accordingly, each applicant access requestcontains a unique ID regardless of whether two or more applicants are“linked” to the same account. For example, if a husband and wife aresharing an account (i.e., both applicants are “linked” to the sameprimary account number) and each submits an access request for a customcard image, a separate unique ID is created for each submission.

The browser-based user interface is used to locate a preferred applicantimage, select the image and upload the image. Image upload may be from ascanner, internet or any other medium device able to interface with theapplicant's computer. Card customization may involve the use of imagemanipulation functions that allow applicants to rotate, flip, reset orresize the custom image to reflect the exact position the image willappear on the card. Using WYSIWYG (“What You See Is What You Get”)technology, the card image shown on the site will be substantially anexact replica of what will appear on the actual issued card. Once theapplicant has determined the precise image fit on the card, the designmay be previewed prior to submission. If satisfied, the applicantselects a “Submit” button and the confirmation screen appears.

The resulting image files are very large given the amount of pixels eachimage requires, thus presenting certain challenges with respect to filetransfer and storage. Accordingly, operations and systems efforts arecoordinated to ensure maximum efficiencies in file processing. Issuersparticipating in the program may provide information concerningprojected system use including the number of card programs to beemployed. Additionally, for each program provided, the issuer mayprovide information including, but not limited to: (1) the number ofapplicants in the program; (2) the projected percentage of applicantparticipation in the program; (3) the projected rate of applicant customimage requests (e.g., number of cards per time period); (4) the numberof years the program is expected to reach its peak; (5) the timing ofplanned promotions/advertising that would direct traffic to the site toinclude the expected increase in traffic resulting from thepromotion/advertising; (6) the capacity of the internet connection tothe server on which the image file will be received; and (7) theestimated image size (maximum of two megabytes for each image).

Thus, it is seen that methods for providing long term storage andretrieval of customized transaction card images is provided. One skilledin the art will appreciate that the present invention can be practicedby other than the various embodiments and preferred embodiments, whichare presented in this description for purposes of illustration and notof limitation, and the present invention is limited only by the claimsthat follow. It is noted that equivalents for the particular embodimentsdiscussed in this description may practice the invention as well.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not of limitation. Likewise, the various diagrams maydepict an example architectural or other configuration for theinvention, which is done to aid in understanding the features andfunctionality that may be included in the invention. The invention isnot restricted to the illustrated example architectures orconfigurations, but the desired features may be implemented using avariety of alternative architectures and configurations. Indeed, it willbe apparent to one of skill in the art how alternative functional,logical or physical partitioning and configurations may be implementedto implement the desired features of the present invention. Also, amultitude of different constituent module names other than thosedepicted herein may be applied to the various partitions. Additionally,with regard to flow diagrams, operational descriptions and methodclaims, the order in which the steps are presented herein shall notmandate that various embodiments be implemented to perform the recitedfunctionality in the same order unless the context dictates otherwise.

Although the invention is described above in terms of various exemplaryembodiments and implementations, it should be understood that thevarious features, aspects and functionality described in one or more ofthe individual embodiments are not limited in their applicability to theparticular embodiment with which they are described, but instead may beapplied, alone or in various combinations, to one or more of the otherembodiments of the invention, whether or not such embodiments aredescribed and whether or not such features are presented as being a partof a described embodiment. Thus the breadth and scope of the presentinvention should not be limited by any of the above-described exemplaryembodiments.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as meaning “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof; the terms “a” or“an” should be read as meaning “at least one,” “one or more” or thelike; and adjectives such as “conventional,” “traditional,” “normal,”“standard,” “known” and terms of similar meaning should not be construedas limiting the item described to a given time period or to an itemavailable as of a given time, but instead should be read to encompassconventional, traditional, normal, or standard technologies that may beavailable or known now or at any time in the future. Likewise, wherethis document refers to technologies that would be apparent or known toone of ordinary skill in the art, such technologies encompass thoseapparent or known to the skilled artisan now or at any time in thefuture.

A group of items linked with the conjunction “and” should not be read asrequiring that each and every one of those items be present in thegrouping, but rather should be read as “and/or” unless expressly statedotherwise. Similarly, a group of items linked with the conjunction “or”should not be read as requiring mutual exclusivity among that group, butrather should also be read as “and/or” unless expressly statedotherwise. Furthermore, although items, elements or components of theinvention may be described or claimed in the singular, the plural iscontemplated to be within the scope thereof unless limitation to thesingular is explicitly stated.

The presence of broadening words and phrases such as “one or more,” “atleast,” “but not limited to” or other like phrases in some instancesshall not be read to mean that the narrower case is intended or requiredin instances where such broadening phrases may be absent. The use of theterm “module” does not imply that the components or functionalitydescribed or claimed as part of the module are all configured in acommon package. Indeed, any or all of the various components of amodule, whether control logic or other components, may be combined in asingle package or separately maintained and may further be distributedacross multiple locations.

Additionally, the various embodiments set forth herein are described interms of exemplary block diagrams, flow charts and other illustrations.As will become apparent to one of ordinary skill in the art afterreading this document, the illustrated embodiments and their variousalternatives may be implemented without confinement to the illustratedexamples. For example, block diagrams and their accompanying descriptionshould not be construed as mandating a particular architecture orconfiguration.

1. A method for providing long term storage of customized transactioncard images, comprising the steps of: (a) approving or rejecting aselected customized image; (b) marking the customized image as approvedor rejected; (c) packaging the customized image into an image file for atransaction card issuer; (d) sending the image file to the transactioncard issuer via a secure transfer process; and (e) sending the imagefile to long term storage; wherein step (a) is performed by an imagereviewer of the transaction card issuer; wherein steps (b), (c), (d) and(e) are performed by an image review application.
 2. The method of claim1, wherein the step of sending the image file to long term storagecomprises sending the image file to an image archive database of atransaction card franchiser.
 3. The method of claim 2, wherein storingthe image file on the franchiser database is performed to supplement acard replacement program of the transaction card issuer.
 4. The methodof claim 1, wherein the step of sending the image file to long termstorage is performed after a predetermined amount of time has elapsedsince sending the image file to the transaction card issuer.
 5. Themethod of claim 4, wherein the predetermined amount of time comprises 30days.
 6. The method of claim 1, wherein a transaction card applicant mayrequest a customized image for lost, stolen, or expired cards through animage administrator.
 7. The method of claim 6, wherein requesting thecustomized image comprises logging on to the image administrator,requesting the customized image through a card replacement section ofthe image administrator, navigating the card replacement section,entering a unique image identifier, and receiving confirmation that therequest is in process.
 8. The method of claim 6, wherein, upon receivingthe request, the image administrator locates the customized card imagevia the unique image identifier, automatically approves the request,retrieves the customized image from an image archive, and places thecustomized image in an image queue.
 9. The method of claim 8, furthercomprising the step of sending the customized image to a card processorfor transaction card replacement.
 10. The method of claim 1, wherein,upon receiving a request for a customized image for a lost, stolen, orexpired card, an image administrator locates the customized card imagevia the unique image identifier, automatically approves the request,retrieves the customized image from an image archive, and places thecustomized image in an image queue.
 11. A method for providing retrievalof customized transaction card images from long term storage, the methodcomprising the steps of: (a) requesting retrieval of a selectedcustomized image; (b) retrieving the customized image from long termstorage; (c) setting customized image status to re-send; (d) packagingthe customized image into a customized image file; and (e) sending thecustomized image file to a transaction card issuer via a secure transferprocess; wherein steps (a) and (b) are performed by the transaction cardissuer using an image review application; wherein steps (c), (d) and (e)are performed by the image review application.
 12. The method of claim11, wherein a transaction card applicant may request a customized imagefor lost, stolen, or expired cards through an image administrator. 13.The method of claim 12, wherein requesting the customized imagecomprises logging on to the image administrator and requesting thecustomized image through a card replacement section of the imageadministrator.
 14. The method of claim 13, wherein requesting thecustomized image further comprises entering a unique image identifier.15. The method of claim 13, wherein upon receiving the request, theimage administrator locates the customized card image via the uniqueimage identifier, and automatically approves the request.
 16. The methodof claim 11, further comprising the step of sending the customized imageto a card processor for transaction card replacement.
 17. The method ofclaim 11, wherein the customized transaction card images are stored inan image archive database of a transaction card franchiser.
 18. Themethod of claim 17, wherein storing the customized transaction cardimages on the franchiser database is performed to supplement a cardreplacement program of the transaction card issuer.